A memory device, such as a smart card or an SD card, can be used as an embedded secure module in a host, such as a personal computer (PC) or a mobile phone, to simultaneously support multiple tasks and application streams from the host. Access to the secure module is often asynchronous because applications running on the host are often not synchronized and because a secure module may only be able to execute a single operation at any moment in time. As a result, multiple applications on a host may need to time-share the secure module. As shown in FIG. 5, data from two or more different applications are divided into multiple blocks and are stored in two or more data buffers until the blocks can be processed by the secure module. In applications such as security processing (e.g., digital signature and encryption generation), blocks of data cannot be processed separately, as the processing of a given block depends on previously-processed blocks. Therefore, when processing two concurrent streams, the current context is saved in the secure module and later used for processing subsequent blocks. However, saving the context in the secure module can consume a relatively-large amount of memory, which can be a problem for memory devices, such as smart cards and SD cards, that have limited memory space. When used as secure modules, such storage devices may further require a special state management block, which can significantly increase the price of the secure module. Also, the performance of the secure module can significantly decrease because repeatedly writing the context to non-volatile memory can take a relatively-long time and decrease the life cycle of the non-volatile memory.
Another difficulty encountered with security processing in secure modules is that the time needed to complete a security operation (e.g., RSA key generation or RSA signature) can be longer than a maximum response time for the memory device to respond to the command. Smart cards deal with this situation by using a special “not ready” command (such as a “NULL” procedure byte defined in ISO-7816-3) to instruct the host to keep waiting (see FIG. 6). However, with this approach, the host may need to wait a relatively-long time until the operation is complete and may not be able to interrupt the operation. Additionally, there is a risk that the host driver could put the secure module in sleep mode during this time, which can result in the secure module's volatile memory being erased. Further, for some secure modules, such as SD cards, such special “not ready” commands cannot be implemented since they are not defined at the physical protocol level.